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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2006). 
Abstract 


The Presence Information Data Format (PIDF) defines a basic XML 
format for presenting presence information for a presentity. The 
Contact Information for the Presence Information Data format (CIPID) 
is an extension that adds elements to PIDF that provide additional 
contact information about a presentity and its contacts, including 
references to address book entries and icons. 
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1. Introduction 


Presence information facilitates communication; its usefulness can be 
enhanced by providing basic information about a presentity or 
contact. This specification describes a basic set of information 
elements that allow a watcher to retrieve additional information 
about a presentity or contact. 


This specification defines extensions to the PIDF [9] Extensible 
Markup Language [7][8][10] (XML) document format. 


We describe elements for providing a "business card", references to 
the homepage, map, representative sound, display name, and an icon. 
This additional presence information can be used in PIDF [9] 
documents, together with Rich Presence Information Data format [11] 
(RPID), future-status [12], and other PIDF extensions. 


All elements extend the <person> or, less commonly, <tuple> element 
in the presence data model [13]. The <tuple> element is only 
extended with Contact Information for the Presence Information Data 
format (CIPID) elements if the information describes a service 
referring to another person that is marked by an RPID <relationship> 
element with a value other than ’self’. All elements described in 
this document are optional. 


Schulzrinne Standards Track [Page 2] 


RFC 4482 CIPID July 2006 


RPID and CIPID both provide "rich" presence that goes beyond the 
basic ’open’ and ‘closed’ status information in PIDF. The presence 
information described in these two documents can be supplied 
independently, although in practice, both will often appear in the 
same PIDF document. CIPID elements describe the more static aspects 
of somebody’s presence information, while RPID focuses on elements 
that will likely change throughout the day. Thus, CIPID information 
can often be statically configured by the user through the graphical 
user interface of a presence client; this is less likely to be 
sufficient for RPID. 


The namespace URI for these elements defined by this specification is 
a URN [2], using the namespace identifier ’ietf’ defined by [4] and 
extended by [6]: 


urn:ietf:params:xml:ns:pidf:cipid 
2. Terminology and Conventions 
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 


RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted 
as described in BCP 14, RFC 2119 [1]. 


3. CIPID Elements 


Unless otherwise noted below, each element may only appear at most 
once. 


3.1. Card Element 


The <card> element includes a URI pointing to a business card, e.g., 
in LDAP Data Interchange Format [15] (LDIF) or vCard [14] format. 


3.2. Display-Name Element 


The <display-name> element includes the name identifying the tuple or 
person that the presentity suggests should be shown by the watcher 
user interface. It is left to the watcher user interface design to 
choose whether to heed this suggestion or to use some other suitable 
string. The CIPID information MAY contain multiple display names, 
but only if they are labeled with different ’xml:lang’ attributes. 
This allows a Korean-speaking presentity to convey its display name 
in different languages, Latin and Hangul, for example. 


3.3. Homepage Element 


The <homepage> element provides a URI pointing to general information 
about the tuple or person, typically a web home page. 
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3.4. Icon Element 


The <icon> element provides a URI pointing to an image (icon) 
representing the tuple or person. The watcher can use this 
information to represent the tuple or person in a graphical user 
interface. Presentities SHOULD provide images of sizes and aspect 
ratios that are appropriate for rendering as an icon. Support for 
JPEG, PNG, and GIF formats is REQUIRED. 


3.5. Map Element 


The <map> element provides a URI pointing to a map related to the 
tuple or person. The watcher can use this information to represent 
the tuple or person in a graphical user interface. The map may be 
either an image, an HTML client-side image map, or a geographical 
information system (GIS) document, e.g., encoded as GML. Support for 
images formatted as PNG and GIF is REQUIRED. 


3.6. Sound Element 


The <sound> element provides a URI pointing to a sound related to the 
tuple or person. The watcher MAY use the sound object, such as a 
MIDI or MP3 file, referenced by the URL to inform the watcher that 
the presentity has assumed the status OPEN. Implementors are advised 
to create user interfaces that provide the watcher with the 
opportunity to choose whether to play such sounds. Support for 
sounds coded as MPEG-2 Layer 3 (MP3) is RECOMMENDED. The sound 
object might also be used to indicate how to pronounce the 
presentity’s name. 


4. Example 
An example using CIPID only is shown below: 


<?xml version="1.0" encoding="UTF-8"?> 

<presence xmlns="urn:ietf:params:xml:ns:pidf" 
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" 
xmilns:c="urn:ietf:params:xml:ns:pidf:cipid" 
entity="pres:someone@example.com"> 


<tuple id="bs35r9"> 
<status> 
<basic>open</basic> 
</status> 
<contact priority="0.8">im:alice@example.net</contact> 
<timestamp>2005-11-21T16:14:29Z</timestamp> 
</tuple> 
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<dm:person id="p1"> 
<c:card>http://example.com/~alice/card.vcd</c:card> 
<c:display-name>Alice Lewis</c:card> 
<c:homepage>http://example.com/~ alice</c:homepage> 
<c:icon>http://example.com/~alice/me.png</c:icon> 
<c:map>http://example.com/”~ alice/gml-map.xml</c:map> 
<c:sound>http://example.com/~alice/hello.wav</c:sound> 
<dm:timestamp>2005-11-21T09:00:00+05:00</dm:timestamp> 

</dm:person> 

</presence> 


An example combining RPID and CIPID is shown below: 


<?xml version="1.0" encoding="UTF-8"?> 

<presence xmlns="urn:ietf:params:xml:ns:pidf" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmilns:dm="urn:ietf:params:xml:ns:pidf:data-—model" 
xmilns:c="urn:ietf:params:xml:ns:pidf:cipid" 
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid" 
xsi:schemaLocation="urn:ietf:params:xml:ns:pidf pidf.xsd 
urn:ietf:params:xml:ns:pidf:data-model data-model.xsd 
urn:ietf:params:xml:ns:pidf:cipid cipid.xsd 
urn:ietf:params:xml:ins:pidf:rpid rpid.xsd" 
entity="pres:someone@example.com"> 


<tuple id="bs35r9"> 
<status> 
<basic>open</basic> 
</status> 
<contact priority="0.8">im:someone@mobile.example.net</contact> 
<timestamp>2005-05-30T22:00:29Z</timestamp> 
</tuple> 


<tuple id="bs78"> 

<status> 
<basic>closed</basic> 

</status> 
<r:relationship><r:assistant/></r:relationship> 
<c:card>http://example.com/~assistant/card.vcd</c:card> 
<c:homepage>http://example.com/”~ assistant</c:homepage> 
<contact priority="0.1">im:assistant@example.com</contact> 
<timestamp>2005-05-30T22:00:29Z</timestamp> 

</tuple> 


<dm:person id="p1"> 
<c:card>http://example.com/~ someone/card.vcd</c:card> 
<c:homepage>http://example.com/~ someone</c:homepage> 
<c:icon>http://example.com/~ someone/icon.gif</c:icon> 
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<c:map>http://example.com/~ someone/gml-map. xml</c:map> 
<c:sound>http://example.com/~ someone/whoosh.wav</c:sound> 
<dm:timestamp>2005-05-30T22:02:44+05:00</dm:timestamp> 


</dm:person> 


</presence> 


5. The XML Schema Definition 


The schema is shown below. 


<?xml version="1.0" encoding="UTF-8"?> 

<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:cipid" 
xmlns:cipid="urn:ietf:params:xml:ns:pidf:cipid" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified"> 


<xs:annotation> 
<xs:documentation> 

Describes CIPID tuple extensions for PIDF. 
</xs:documentation> 

</xs:annotation> 


<xs 
<xs 
<xs 
<xs 
<xs 
<xs 


:element 
:element 
:element 
:element 
:element 
:element 


</xs:schema> 


Schulzrinne 


name="card" type="xs:anyURI"/> 
name="display-name" type="xs:string"/> 
name="homepage" type="xs:anyURI"/> 
name="icon" type="xs:anyURI"/> 
name="map" type="xs:anyURI"/> 
name="sound" type="xs:anyURI"/> 


Figure 1: CIPID schema 
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6. IANA Considerations 


This document calls for IANA to register a new XML namespace URN and 
schema per [6]. 


6.1. URN Sub-Namespace Registration for 
‘urn:ietf:params:xml:ns:pidf:cipid’ 


URI: urn:ietf:params:xml:ns:pidf:cipid 

Description: This is the XML namespace for XML elements defined by 
RFC 4482 to describe contact information presence information 
extensions for the status element in the PIDF presence document 
format in the application/pidf+xml content type. 

Registrant Contact: IETF, SIMPLE working group, simple@ietf.org; 
Henning Schulzrinne, hgs@cs.columbia.edu 

XML: 


BEGIN 
<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" 
"http: //www.w3.org/TR/xhtml-basic/xhtml-basicl0.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml 
<head> 
<meta http-equiv="content-type" 
content="text/html; charset=iso-8859-1"/> 
<title>CIPID: Contact Information for the Presence Information 
Data Format</title> 
</head> 
<body> 
<hl>Namespace for contact information presence extension 
(status) </h1> 
<h2>urn:ietf:params:xml:ns:pidf:cipid</h2> 
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4482.txt"> 
RFC4482</a>.</p> 


</body> 
</html> 
END 
6.2. Schema Registration for Schema ’urn:ietf:params:xml:ns:pidf:cipid’ 
URI: urn:ietf:params:xml:ns:pidf:cipid 


Registrant Contact: IESG 
XML: See Figure 1 
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7. 


Internationalization Considerations 


CIPID delivers only URLs, except for the <display-name> element. The 
resolution of the URLs can negotiate appropriate language and 
character sets within the URL-designated protocol. 


For the display name and to handle Internationalized Resource 
Identifiers (IRIs) [16], since CIPID is represented in XML, it 
provides native support for encoding information using the Unicode 
character set and its more compact representations including UTF-8. 
Conformant XML processors recognize both UTF-8 and UTF-16. Though 
XML includes provisions to identify and use other character encodings 
through use of an "encoding" attribute in an <?xml?> declaration, use 
of UTF-8 is RECOMMENDED in environments where parser encoding support 
incompatibility exists. 


The XML ’xml:lang’ attribute can be used to identify the language and 
script for the <display-name> element. The specification allows 
multiple occurrences of this element so that the presentity can 
convey display names in multiple scripts and languages. If no ’xml: 
lang’ attribute is provided, the default value is "i-default" [3]. 


Security Considerations 


The security issues are similar to those for RPID [11]. Watchers 
need to restrict which content types of content pointed to by <icon>, 
<homepage>, <map>, <sound>, and <vcard> elements they render. 


Also, when a watcher accesses these URIs, the presentity may deduce 
that the watcher is currently using the presence application. Thus, 
a presence application concerned about leaking this information may 


want to cache these objects for later use. (A presentity could 
easily customize the URLs for each watcher, so that it can tell who 
is referencing the objects.) This caching behavior may cause the 


information to become stale, out-of-syne with the current data until 
the cache is refreshed. Fortunately, the elements in CIPID are 
expected to retain the same content for periods measured in days, so 
that privacy-conscious applications may well decide to perform 
caching over durations that reveal little current activity 
information. Presentities need to keep in mind that clients may 
cache the content referenced by URIs for long periods as they use 
their presence system to construct presence documents using this 
extension. If the referenced content needs to change frequently, the 
presentity could, for example, update the presence document with a 
new URI to encourage clients to notice. 
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9. 


9. 


Icons and other URIs in this document could be used as a covert 
channel to convey messages to the watcher, outside the content 
monitoring that might be in place for instant messages or other 
communications channels. Thus, entities that worry about such 
channels may want to prohibit the usage of URLS pointing to resources 
outside their domain, for example. 


Implementors must take care to adhere to the mechanisms for verifying 
the identity in the referenced server’s certificate against the URI. 
For instance, if the URI scheme is https, the requirements of RFC 
2818 [5], section 3.1, must be met. In particular, the domain 
represented in the URI must match the subjectAltName in the 
certificate presented by the referenced server. If this identity 
check fails, the referenced content SHOULD NOT be retrieved and MUST 
NOT be used. 
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